Business Analyst Community & Resources | Modern Analyst

Three Audacious Goals for Business Analysts in 2013

Jarett Hailes — Wed, 02 Jan 2013 19:07:00 GMT

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals.

Merriam-Webster defines audacious as “intrepidly daring” and “marked by originality”. As the business analysis profession and Business Analyst community continue to mature, more organizations are seeing the value that professionally-executed business analysis can bring. Business Analysts have an opportunity to help organizational leaders achieve their vision for the future. Here are three audacious goals for 2013 to help Business Analysts capitalize on this opportunity.

1. Move Beyond Information Technology Solutions

Most Business Analysts are focused on the development of IT solutions to meet business needs. The ‘IT Business Analyst’ has been hailed as key cog in the overall IT delivery framework for organizations.

While information technology is one crucial supporting function every organization needs, it is not the only area where Business Analysts can deliver value. Technology is only effective if there people who know how to use it and processes that will ensure the overall business is able to perform tasks in an efficient and effective manner. Business Analysts need to ensure that all three of these aspects work together by identifying and assessing requirements for all components, not just the technology-related pieces.

Business Analysts can challenge the perception that their work solely fits into IT by demonstrating their ability to consider the process and people components during their prescribed activities. Go beyond writing system specifications and point out potential challenges that people will have with a complicated screen layout, or identify regulatory or policy issues that will impact certain functional requirements. Such actions will allow clients to see the need for a more holistic approach to solution development and can improve the high failure rates seen by projects that are ostensibly driven by IT. Even if you are working in a systems support role, you have the opportunity to present a more complete picture about proposed modifications that will allow everyone to realize how an application should be changed to meet the organization’s needs.

2. Master and Leverage Complementary Disciplines

As a Business Analyst you already rely on competencies and knowledge from other disciplines. Most business analysis knowledge areas use notions from areas such as systems analysis, project management and facilitation.

There are several disciplines that provide wonderful skills and techniques that Business Analysts can use to help accomplish their daily tasks more effectively. If you take the time to learn and master one or more of these disciplines, your value to your organization can increase exponentially. Not only do you improve your career options but you become a better Business Analyst by being able to deal with a greater breadth of problems.

Some of the disciplines that are worth mastering as a Business Analyst are:

· Change Management: understanding how people deal with change and how to help navigate organizations through change is a crucial set of skills in today’s environment. Business Analysts can leverage change management practices throughout their activities, most noticeably in stakeholder analysis, requirements management, requirements analysis and enterprise analysis.

· Mediation/Conflict Resolution: with change comes the possibility of interpersonal conflicts. People can disagree for a variety of rational and irrational reasons. Business Analysts are often at the forefront of such conflict while they attempt to define and manage requirements. Understanding how to assess a conflict’s root cause and having techniques to defuse volatile situations are crucial to help gain consensus and keep a project moving forward.

· Performance Measurement: Business Analysts can play an important role in reviewing existing solutions or working on the business case for change. Being able to define and implement relevant measures to evaluate individual solutions or an overall organization are key tools that are needed to help keep companies moving forward. Knowing how to leverage methodologies such as Lean and Six Sigma make doing these tasks that much easier.

3. Use Your Skills to Give Back

Many Business Analysts already volunteer their time to causes they believe in, but it may not be in a capacity that leverages their professional skills. Business Analysts can get a lot out of using their skills to give back to others, while at the same time helping their community. Not only is there the satisfaction of helping those in need, but an opportunity to learn how to take the experiences from such efforts and apply them in their organizations of employment. There are opportunities to help organizations who need Business Analysts as well as helping our fellow Business Analysts improve.

Here are some ideas on how to give back:

· Find a local non-profit or charity who could benefit from some business analysis but don’t have the in-house expertise or financial resources to perform the analysis.

· If you like to volunteer in developing countries, speak with the organization you work with to see if you can help them improve their operations or help them with a specific project that requires business analysis. We already have “Doctors without borders” and “Engineers without borders” – why not “Business Analysts without borders”?

· Pay it forward: mentor a less experienced Business Analyst so they can share their knowledge and expertise in the future with others.

· Start a community of practice with other BAs either inside or outside your organization to help improve everyone’s collective maturity and share ideas on how to perform BA activities better.

· Work with your local IIBA chapter to put on an event that will help the BA community grow.

What are your professional goals for 2013? Do you have any audacious goals?

Hey IIBA, What’s Up With That?

Howard Podeswa — Mon, 08 Oct 2012 06:07:00 GMT

Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession.

Hi xx

…. Regarding the IIBA talk, there is another issue that I am considering. It's part of a longer discussion, and I hesitate to draw you into it, but as it affects my response to your invitation I feel it requires some explanation. Basically, I have been very unhappy with the direction the organization has been taking and have been seriously reconsidering my - and my company's - relationship to it in lieu of recent developments. When I first joined the organization, back in its founding days, I, like many other volunteers who gave their time freely, without charge, to review the BABOK, saw the organization as a means for improving the profession by pooling together the resources of its practitioners so that best practices could be disseminated widely amongst the community. I fear the organization has steered off-track, and have great reservations regarding what it is becoming - or already has become. The recent EEP contract changes have only served to confirm my worst fears: students taking any training that 'uses' more than 3 sections of the BABOK will be required to purchase the entire BABOK - even if they already have a copy. In fact, it has been clarified to me that they will be required to purchase the book each time they take such a course - raising the spectre of trainees forced to purchase multiple copies of the BABOK due to courses they have taken with multiple vendors. It's a heavy-handed approach (and potential book-keeping nightmare) that will only serve to restrict the propagation of BABOK practices - where the IIBA should be seeking to do the reverse: open up the BABOK so it is as widely used as possible. For a comparison of approaches, see the OMG, which offers its UML standards and guidelines as a free download to all who want it (member or non-member) and which is very generous in providing permission to quote its text in printed publications. This is what an organization does whose first and foremost goals is to propagate best practices.

The IIBA faces an identity crisis: is it to be a revenue-generating machine, dedicated foremost to its own financial success, or a service to the BA profession?

These are some of my thoughts and concerns. If you'd like to continue this conversation, I'd be pleased to discuss it further.

Best regards
- Howard

Howard Podeswa - Noble Inc.

BA ABCs: “C” is for Class Diagram

Adrian M. — Thu, 01 Mar 2012 06:36:00 GMT

Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post.

You can find the article here:

BA ABCs: “C” is for Class Diagram

Here are the previous two posts:

BA ABCs: “A” is for Activity Diagram

BA ABCs: “B” is for BPMN

Thoughts on the Agile Extension of the BABOK

Jarett Hailes — Thu, 01 Mar 2012 02:23:00 GMT

Today was the last day people could provide feedback to the IIBA’s Agile Extension of the BABOK. The most recent draft of the document was published in November 2011 for review and comment. The purpose of the extension is to provide readers an understanding of how business analysis can be performed within an Agile environment. Various Agile methodologies such as Scrum, XP and Kanban are presented in high level summaries, and then business analysis activities from the BABOK are mapped to the main events that occur in the general Agile environment. Finally, a list of techniques that can be applied to the BABOK activities in an Agile setting are presented.

Overall the document is well written and does a good job of describing how business analysis fits into an Agile setting. This is a topic that has been much discussed in the past few years, and two years ago I wrote an article that summarized several leading Agile experts’ views on how the Business Analyst role fits into the evolving Agile framework. As Agile methodologies continue to gain traction in corporate software development processes, it makes sense to ensure that Business Analysts feel comfortable with how their skills transition to a different environment.

That said I have a concern about having such an extension does to the perception of business analysis as a profession and to Business Analysts as a role. I do not see business analysis as some activity that is merely a component of software development or IT solution delivery. Business Analysts can play a strategic role in the organization to help ensure that the organization is capitalizing on its opportunities and adapts efficiently to changing market, regulatory and internal cultural changes. When BAs are deployed throughout an organization they can get a hands on sense of what’s working, what’s not, and can draw upon technical and behavioural expertise to find innovative ways to help the organization continually improve its operations. I have had the opportunity with several clients to step outside of IT departments and play such a role, and not only is it personally rewarding but it is also where I have been able to provide the most value.

In many organizations I come into contact with business analysis is perceived as some 'IT thing' done to 'help the techies figure out what the business wants'. This perception often comes found the originations of professional business analysis, and while understandable, it is something that must be challenged in order to unlock the potential of having professional Business Analysts throughout the organization working on problems that are not limited to an IT solution scope.

The second version of the BABOK made great strides towards demonstrating how business analysis can be performed outside of IT and explained why it is needed by organizations to adapt to today's constantly changing environments. While some organizations are starting to see the value of BAs outside of IT, having a document such as the Agile extension reinforces existing preconceptions of business analysis in a limited role. In some ways publishing an Agile extension seems like a mea culpa to the wider business audience, indicating that it is wrong to think of business analysis outside of a software development context. I am sure this is not the intention of the IIBA, but given the stage of development of the profession it may be an unintended consequence.

I have been meeting with several executives, managers of Business Analysts and consulting business development personnel in a study group of the BABOK. Through their reading and discussion of the BABOK’s concepts they have come to recognize the value of the information outside of an IT setting, which has taken some work given that while the BABOK V2 is more generic than before, many of the concepts and examples rely heavily on the IT domain. When I mentioned that there was now an Agile extension, most wondered if in fact we had all been reading too deeply into the BABOK; maybe it was just for IT environments after all.

Perhaps I am being too harsh on having such an extension – after all the Project Management Institute has a construction industry extension to the PMBOK, which is one of the industries that were a main influence in the beginning of the institute, as well as for government. The PMI even has an Agile practitioner certification, which is decidedly focused on software development. Nonetheless, I feel that given the developmental stage of business analysis as a profession, having such an extension sends mixed messages on the applicability of the body of knowledge, and limits the career opportunities for Business Analysts in the near term.

As I mentioned above I think the content is valuable and good for BAs who are working in the IT domain to know, but I believe that some other term may be been better suited to describing the document. Calling it an extension of the BABOK ties it too heavily to the general body of knowledge in my mind. I could have seen this as a valuable ‘industry application guide’ or something along those lines.

What are your thoughts on the Agile extension? Do you like the content? What do you think that such an extension does to the perception of business analysis in general and outside of the IT domain in particular?

10 Things I Wish Someone Had Told Me When I Was Starting Out As A BA

Howard Podeswa — Tue, 15 Feb 2011 05:32:00 GMT

I am no longer a Webinar virgin. Thanks to the good folks at the IIBA, this week I had my first Webinar experience as an interviewee as part of the IIBA’s ‘ABC’ (Authors, Books and Conversations) series. The host, Julian Sammy, was brilliant in being able to pick out the questions that would be the most difficult for me to answer. (I hear that’s what makes him a great BA, too.) Of course, afterwards, I was regretting not being able to do a ‘do-over’ – until I remembered that I could – sort of – thanks to my MA blog.

Julian’s toughest questions were about the 3-way connection I saw between psychology, business analysis and art; I’ll leave that for later. But there was a BA question that I didn’t have a ready answer for, “What are the most important things you wish you had known when you were starting out as a BA?” Maybe it’s because it’s been so long since I have been in that position. But the memories have begun to come back.

So, for Julian - and anyone else who might be interested: here, then, after some thought, is what I wished someone had told me when I was starting out:
1. See every BA engagement as an opportunity to learn about other people - and not just to learn about another system: I thought my success or failure as a BA would be all about my analysis skills. I have since found out it hinges more on my ability to connect with people from a wide variety of backgrounds and cultures.

2. Turn off the inner monologue while listening to other people. (See #1 above).

3. Find out, from day 1, who will have ultimate signing authority – then meet that person as soon as possible: I’ve had bad shocks early in my career when I found out that the one person I really needed to convince was the one person I didn’t know about - until it was too late. I now do everything in my power to bring that person into the process ASAP.

4. Don’t go off for too long on your own: In my earlier days, I would do a big round of interviews and then go off for a long period to produce a big ‘tome’ of documentation. I found out soon enough that it’s too much for stakeholders to absorb at once and it’s too easy to propagate mistakes – like too much or the wrong kind of documentation. Now I provide feedback frequently to stakeholders.

5. The only way to get a good user interface is through many iterations of prototyping and user testing – because most people don’t know what they want till they see it. The focus of the BA in this case is to find out what the flow of the interface should be from the user’s perspective (the ‘Basic Flow’ – in use-case parlance), as well as the alternative scenarios that need to be addressed, while the designer works to realize these flows in the prototypes.

6. Test assumptions as early as possible in order to mitigate risk – especially if this is something you (or your organization) is doing for the first time: I’ve personally worked on 2 major projects where untested assumptions about new technology resulted in long delays and lots of rework once they were found to be untrue - and I have direct knowledge of many more projects that have suffered the same fate. By testing assumptions early I am now able to reduce the impact of unexpected problems.

7. Budget your time wisely: In the early days, I blew too much analysis time on small parts of the business area. I am much more careful now in planning and budgeting my time. I’ve learned to work top-down; in the beginning, I concentrate on the big picture and work my down into the weeds as the project progresses.

8. There is almost always a hidden agenda: For any non-trivial project, there is bound to be some aspect of office politics that can make or break the project. In many cases I have ended up being an unwitting pawn in someone else’s power play. In one case, for example, there were warring departments, each of which had already made up its mind about the preferred solution; the hidden agenda of the project champion who brought me onboard was to get an ‘unbiased expert’ to recommend his preference.

9. Don’t solutionize the requirements: The requirements as written, should make sense regardless of the technology solution. Otherwise, they will not be reusable should the preferred solution change – leading to lost time and effort.

10. The clients already know the answer: This is the secret lesson of consulting that I learned at the hands of a colleague (Brian Lyons) – and I’ve found it to be true more often than not. In many cases (such as process improvement projects), the clients know what’s wrong and what they need to do about it - and are really looking to the BA to confirm what they already know, or to help them formulate their thoughts. Yet another reason why it’s more important to listen than to talk.

And what about that question about psychology, business analysis and art (all of which are interests of mine)? The flippant answer is to say that these interests co-exist but they don’t necessarily connect. By maybe they do. I have an endless curiosity about people and how they live their lives – and it is a curiosity that the BA profession has helped me satisfy. As well, I have always been interested in the structure of thought – a theme that underlies both cognitive psychology as well as structural analysis. My art similarly has two recurring themes - often concerned either with the psychology of an interaction (see this series based on my experiences in South Africa) or with the way the mind organizes information (see this link for work based on organizing visual bytes of information).

So maybe there is some connecting thread to it after all.

- Howard Podeswa

What are the Quantitative Benefits of Business Analysis?

Howard Podeswa — Sat, 27 Nov 2010 08:21:00 GMT

At the end of my IIBA Webinar I tossed out a question to listeners: What are the quantitative benefits of business analysis?

It’s something I’ve been spending some time on. While there are many touted (and self-obvious) benefits of analysis , hard figures are hard to come by – and it’s hard figures that high-level executives want to see when we make the case for the profession. Fellow BAs have begun to take me up on the challenge and I have, at the same time, been meeting with CEO, CFOs, CIOs and others in upper-level management. So I thought it was time to throw out the question to the collective wisdom of the Modern Analyst community. What I’m looking for are measures that quantify either the benefits that have been derived from business analysis or the costs of doing it badly: metrics like the annual cost to projects attributable to a poor requirements analysis process relative to the annual project budget; estimated decrease in turnaround time due to improved analysis, and so on. I’m also looking for war stories – either horror stories of where things went wrong due to poor analysis or uplifting stories when things have gone well – with figures to back it all up where possible. Alternatively – if you have a source of stats on the cost benefits of good requirements that you think is helpful, please pass that one, too.

Readers are invited to post their contributions to this blog or, if confidentiality is required, to contact me directly at howardpodeswa@nobleinc.ca. Once I have a representative response, I’ll be summarizing and posting the results on this site.

(Attached jpg: Caption: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”. Description: “Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

Howard Podeswa of Noble Inc.

Blog Image: “Hi-Lo”, Howard Podeswa, Oil on canvas, 2007, 10 “ x 10”.

“Hi-Lo” is a reconstruction of the painting “The Night Watch” by Rembrandt, created by measuring and graphing the high and low points in the original composition.)

6 Traits Of A Great Business Analyst (And How To Interview For Them)

Jarett Hailes — Tue, 19 Oct 2010 02:16:00 GMT

Whether or not you have ever been a Business Analyst yourself, if you work with enough Business Analysts over time you learn what sort of characteristics make a BA successful. Regardless of the Business Analyst’s skills, experience, domain knowledge or certifications, there are inherent traits that will more often than not help a person succeed in accomplishing business analysis tasks.

Over the years I’ve come to recognize most, if not all, of these traits in individuals whom I and many others have recognized as great Business Analysts. These traits are valuable because they help one thrive in a role that often comes with no authority (but lots of responsibility), can have constantly shifting demands and priorities, a lot of environmental ambiguity, and yet is one that plays a key role in the success or failure of projects, initiatives, and even overall organizational performance.

These traits are not meant to determine whether a person is a competent Business Analyst. Competency in business analysis tasks is something that typically is tied to the ability for an individual to perform BA tasks at a certain level of complexity and autonomy. Usually Business Analysts improve their competency over time with experience and ongoing professional learning. That said I find these traits can partially predict a person’s inherent ability to rapidly improve their competency in business analysis through on-the-job and classroom training and experience.

The neat thing about these traits is that you can structure interview questions and scenarios to actually try and bring these traits to the surface. If you look for these traits while you’re interviewing you will definitely have a leg up in determining if the candidate will be able to work well as a BA in your organization. While you will still want to assess the BA based on their skills, experience, etc., I would highly recommend looking into setting up scenarios during your hiring process that will help you establish whether these traits are inherent in the individual or not. I’ve put some suggestions on how to search for these traits during interviews below.

1. They are engaging

Business Analysts need to do something that is inherently tricky; convince people to commit their time and effort to working on activities that often aren’t their top priority. Rarely does a BA have the project with stakeholders who can commit their full time to requirement elicitation and validation, or have an unlimited amount of time to follow the schedules and priorities of their stakeholders and have requirements gathered when it suits them. Business Analysts often learn how to cajole, coerce, beg and otherwise convince stakeholders to help them accomplish their tasks, but the process is a whole lot easier if the Business Analyst is engaging. A great Business Analyst makes you want to work with them, even if you’re the Director of Sales and they need you to help define performance metrics for the CRM database upgrade.

A Business Analyst that can communicate the value of a project with passion and dedication will inherently pull people in without needing to list off the million reasons you need to be involved. Instead, you’ll want to be involved (or at the very least be willing to be involved more than you otherwise would). Having an engaging Business Analyst can bring everyone to the table and help groups focus on achieving meaningful results in a short amount of time.

How to interview for this trait: Look for the most boring looking project or accomplishment on the candidate’s resume and ask them to describe to them how they were able to perform . Ask them a similar question for what looks to be an interesting or exciting project. Listen to how they deliver their responses. If you feel like you want to hear more from the candidate regardless of the project being discussed, then there’s a good chance that the BA knows how to be engaging regardless of the environment.

You can also ask them about how they’ve dealt with situations where stakeholders were not committing sufficient time/effort to accomplishing tasks and how they overcame it. If the first thing out of their mouth was “I talked to the Project Manager” then you probably have someone who does not believe they can inherently engage stakeholders.

2. They aren’t easily ruffled by conflict

Business Analysts are often faced with unruly or disagreeing stakeholders, unrealistic timelines and potential or actual shifts in scope. Sometimes all their hard work that has been put into gathering, validating and presenting requirements turns out to be completely useless as soon as the sponsor sees the report and says “but I thought we were supposed to build X. That’s what I really need, regardless of what the charter says”. Top that off with trying to get stakeholders to return your calls and e-mails, evaluate the relevancy of 200 business rules in the current software, and fighting with the new requirements management tool and it’s a surprise there aren’t more Business Analysts with frayed nerves.

Like Project Managers, I’ve found that great Business Analysts cannot be easily perturbed. They realize that most of their environment is out of their control, and even though they can often be held accountable for things beyond their scope they take as much as possible in stride. Business Analysts have to be able to handle constantly changing goals, priorities and whims of many stakeholders. While they shouldn’t be simply trying to accommodate everyone without question, they need to realize that it’s all part of the process and that inevitably there will be delays or issues that will impact deliverables and timelines.

How to interview for this trait: It is one thing to say “tell me a time when…,” it’s quite another to actually see someone’s reaction when faced with a situation. After a candidate has responded to a behaviour-based question, one of the interviewers can pretend to become rather rigid and start making assertions that the Business Analyst did not do the correct thing (e.g. “I don’t think you should ever contact the sponsor directly, you should always go through the Project Manager”). Have the interviewer continue to insist on their point as the candidate tries to explain their reasoning or position. Don’t get into any unprofessional conversations such as name calling, but be stubborn. If there’s a hint of a defensive response, then that’s a bad sign. If they take it in stride and are able to accept the interviewer’s opinion, then this is a very good indicator. Business Analysts should expect everyone to have an opinion different from them and know when to move the subject along and acknowledge the person’s point of view.

While I don’t think this technique is suitable for every interview process, I think it can yield insightful responses in many circumstances.

3. They are multi-disciplined

A lot of Business Analysts have expertise and experience in IT and their domain. While this could be considered multi-disciplined I am looking for individuals who have experience in performing tasks in completely unrelated fields across multiple industries. I find that Business Analysts are able to more easily relate to capture information, interact with stakeholders and identify opportunities if they’ve worked in many industries, either as a BA or in an operational role. Great Business Analysts can leverage their knowledge of several disciplines to take techniques and information and apply it to their current project or duties. I find Business Analysts who have been in several industries to be more versatile and less susceptible to believing that certain analysis tools, techniques or work products are what are needed for any and every situation. Business Analysts with an academic background that crosses several disciplines (for example, a degree in Sociology but a Master’s or Doctorate in Math) also demonstrates a multi-disciplined mindset and experience.

A great Business Analyst realizes that all their activities and methods need to be adapted to the specific environment and situation at hand. Multi-disciplined Business Analysts can often find innovative ways to deliver value to their projects and organizations with their wide range of knowledge.

How to interview for this trait: Few people stay in the same field for their entire career, so ask the candidate to discuss a time when they’ve applied knowledge from a job in one field and used it in another field (even if it’s what they learned flipping burgers before heading into investment banking). If the candidate has always been in the same field but has an education in a field that is more or less unrelated to business analysis (Arts, Chemistry, Real Estate, etc.), ask them how they feel that education can help them in a specific BA situation (e.g. “What did you learn with your that would help you be able to ensure that you have a complete set of requirements?”).

4. They are inquisitive

I’ve never met a great Business Analyst that didn’t ask more questions than they answered over the course of a project. Great Business Analysts realize that they are merely a conduit of information and are always asking as many stakeholders as needed to help elicit, refine, validate and implement requirements. A Business Analyst should always be thinking “What, why, how, where, when, who” when they’re communicating with stakeholders and analyzing solutions.

Often Business Analysts won’t get the real information they need the first time around. Whether it’s determining the root cause of a problem, identifying the core need, or ensuring that all the bases are covered when reviewing a potential solution, great Business Analysts realize that while they’ll probably never have a complete set of information they can ask timely and relevant questions to get as much information as possible so effective decisions can be made.

How to interview for this trait: Tell the candidate a little about the project or operational role they will be performing, but keep it high level. If they don’t ask any follow up questions, that’s a major red flag. The more questions and follow ups they ask that are pertinent and relevant, the more likely they are naturally inquisitive and know how to search for important details and considerations. (Note: if they start asking questions like “what’s my vacation pay” and “what are the benefits of the company” before asking for a lot of details about the role, you’re probably looking at the wrong person for your job).

5. They think (and action) strategically

Business Analysts need to always be asking questions about the value of their work. Work that doesn’t relate to the strategic goals of the organization doesn’t just have little value, it’s really fake work. Great Business Analysts understand why what they’re doing has value and can articulate that to stakeholders. In addition, they are always looking for ways to uncover value for the organization by thinking about the organization’s strategic goals. This may lead the BA to recommend the merger of two overlapping projects or highlight the opportunity for process re-engineering that will reduce costs. Great Business Analysts show their companies that they are not simply the “IT guys who don’t just talk tech,” but are people who understand the needs and goals of the organization and can find ways to help them realize their objectives more efficiently.

Great Business Analysts also know how to action on strategic thinking. Rarely will the Business Analyst have the authority to act on an opportunity themselves, but they are willing to develop compelling arguments for superiors to take action. Doing so may place them at a slightly higher level of risk (since they may be going against popular or conventional thinking), but they also do this altruistically for the greater good of the company. I’m not advocating that Business Analysts should be mavericks, but they should know how to communicate the value (or lack of value) in recommendations to superiors.

How to interview for this trait: Give the candidate a scenario for a proposed project. Ask them if they believe the project is a good one to undertake given your company’s goals (assuming the BA could have found these goals on your website or in provided materials prior to the interview). Good candidates for any position should review those goals prior to going to a job interview, and a great Business Analyst should know how to measure a project against those goals.

Also ask the candidate if they’ve ever been on a project where they didn’t think the project was that valuable to the company. Start off by asking them something about the project (how was it run, how did they know it wasn’t valuable, etc.). After they’ve done describing the project, ask them what they did to let others know that the project wasn’t valuable. If they didn’t do anything or very little, then this makes me question whether they can really action on strategic thinking.

6. They care about the details

Most of the above traits are things you want to see in other roles, particularly business leaders and salespeople. One of the things in my mind that sets the Business Analyst role apart from some of these other roles is the need for attention to detail. You can’t be an Analyst without being a little bit anal J Great Business Analysts know the importance of having precise and clear details documented and communicated properly, and are adept at managing large amounts of detailed information.

This also means that a Business Analyst must be able to scale their message and thought processes. A great Business Analyst can give a compelling presentation to executives on the value of a project and then turn around and discuss with a Quality Assurance member why a change to requirement R-1938 impacts test cases T-321 and 329. Without proper attention to detail the Business Analyst can’t ensure that the actual solutions developed or procured will meet the needs of the customer, or even that those needs are sufficiently articulated to be able to adopt solutions.

How to interview for this trait: The best indicator of this trait is to review work products that were exclusively developed by the candidate, although this is often difficult to acquire. Instead you can get the candidate to play the equivalent of Where’s Waldo. Ask the candidate to review a sample deliverable and point out potential issues in the content (e.g. imprecise/ambiguous verbiage in requirements, lack of traceability, etc.). Make sure you give them sufficient time to review the document; this is typically a good activity for a 2^nd or 3^rd interview. The more issues that the candidate uncovers the better (bonus points if they spot stuff you didn’t even intend to be an issue).

I would also evaluate how detailed the candidate’s questions are when asking about the job, the work environment, etc. Again great Business Analysts want as much information as possible, particularly when they’re looking to commit to a position that will take up the majority of their waking hours.

Finding Great Business Analysts

Finding great Business Analysts can take time and effort; hopefully these traits will help you identify individuals with the potential to be great BAs even if they’re in different roles or don’t have the experience yet.

What are some traits of great Business Analysts that you have worked with?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Intermediate Business Analyst Certification Brings Hope for the Junior Business Analyst: CCBA

Chris Adams — Sat, 02 Oct 2010 23:52:00 GMT

The International Institute of Business Analysis (IIBA) has recently announced a new intermediate business analyst certification called the Certification of Competency in Business Analysis (CCBA). The CCBA is being offered by the IIBA as an intermediate business analyst certification for a more junior business analyst who may not meet the more stringent requirements associated with the CBAP.

Timelines for the Certification of Competency in Business Analysis (CCBA)

A junior business analyst will be able to apply to take the Certification of Competency in Business Analysis (CCBA) starting in late 2010. Then in early 2011, a junior business analyst will be able to sit for the exam.

The IIBAs Vision for the Certification of Competency in Business Analysis (CCBA)

For some time now the business analysis community has been voicing the need for an intermediate business analyst certification. In response, the IIBA has developed the Certification of Competency in Business Analysis (CCBA). The IIBA views the CCBA as a stepping stone to the CBAP designation. The CCBA provides recognition for individuals who have business analysis experience and can demonstrate a clear proficiency in business analysis, but don't yet meet the requirements for the more rigorous CBAP designation.

Since the Certification of Competency is Business Analysis (CCBA) is truly intended to be a stepping stone for a junior business analyst to the CBAP designation, the CCBA designation expires after five years. The IIBA anticipates that the CCBA recipient will want to obtain their CBAP designation before the CCBA expires. If this doesn’t happen the recipient of the CCBA does have the opportunity to rewrite the CCBA exam.

Benefits of the Certification of Competency in Business Analysis (CCBA)

The Certification of Competency in Business Analysis can provide a number of benefits to a junior business analyst.

The CCBA designation acknowledges a junior business analyst who has invested in his/her BA career and has obtained a certain level of proficiency in business analysis.
An intermediate business analyst certification like the CCBA can increase the market opportunities available to the junior business analyst.
Preparing for the CCBA can improve overall knowledge and performance as a junior business analyst.

Employers also can benefits from having a junior business analyst receive the Certification of Competency in Business Analysis designation.

Demonstrates within your organization that your team values industry standards and professional certifications.
Provides advancement and recognition opportunities for your staff throughout the rest of the organization.
The CCBA demonstrates to your customers, competitors, and suppliers that you have qualified staff working on your projects.

Application Requirements for the Certification of Competency in Business Analysis (CCBA)

While the IIBA has made the requirements for this intermediate business analyst certification easier to obtain for the junior business analyst, there are still some sizable hurdles to overcome. Each of the following application requirements for the Certification must be met at the time of applying to be approved to sit for the exam.

Minimum 3750 hours of BA work in the last seven years, which is about 2 years of experience doing business analysis work. So this aligns well with the junior business analyst role.
Minimum 900 hours in 2 of the 6 knowledge areas or 500 hours in 4 of the 6 knowledge areas.
Minimum 21 hours of professional development (see the list of IIBA endorsed education providers)
Minimum high school education or equivalent
Two references from
- a career manager
- a client, or
- a CBAP recipient
Signed Code of Conduct

While the application won’t be available until the end of 2010, it probably wouldn’t hurt to know what the CBAP application looks like as they will probably be very similar.

How the Certification of Competency in Business Analysis (CCBA) Breaks Down

Since both the junior business analyst and senior business analyst roles tend to perform the same tasks (the difference is typically in the level of complexity of their work), the Certification of Competency in Business Analysis (CCBA) exam questions break down similarly across the 6 BABOK knowledge areas (v2.0).

Business Analysis Planning & Monitoring	20%
Elicitation	13.33%
Requirements Management and Communication	16%
Enterprise Analysis	15.33%
Requirements Analysis	19.33%
Solution Assessment & Validation	16%

How much does the Certification of Competency in Business Analysis (CCBA) cost?

If you’re planning to sit for the CCBA, be prepared to spend a little bit of money. The application fee alone is $125 USD. Then the exam fee is another $325 USD for IIBA members and $450 USD for non-members.

The annual membership fee for The IIBA is $95 USD. Since members save $125 USD on their exam fees the choice is clear, become a member for $95 USD and save money.

BA ABCs: “B” is for BPMN

Howard Podeswa — Sun, 12 Sep 2010 23:21:00 GMT

#2 in the series: “B” is for BPMN
This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “B” – for Business Process Modeling Notation (BPMN). BPMN is the name of a standard often used for modeling business processes. The diagram covered by the standard is called a Business Process Diagram (BPD).

Example:
Figure 1 is a BPMN BPD that describes the process for reserving a room in a private-members club. The process begins when a member requests a reservation for a specified date. A reservations agent determines the rate and then takes one or more of the followings actions:

If the request included a query about basic rooms, the reservations agent checks the availability of basic rooms.
If the request included a query about deluxe rooms, the reservations agent checks the availability of deluxe rooms.
The slash on the flow marked “Query basic rooms” is a default, indicating this flow is selected if none of the conditions are true.

Next, the member selects a room. When the member’s response is received by the reservations agent, one (and only one) of the following actions is taken:

If the member has cancelled, the reservations process is cancelled.
If the member has selected one of the available rooms, then the reservations agent guarantees the reservations and the process ends in success.

Figure 1 - BPD diagram example: Reserve a room in a private-members club

The controversy: Activity diagram or BPD?

Since activity diagrams (the subject of the previous BA ABCs blog) cover the same ground as BPMN BPDs, the question naturally arises, “Which diagram is ‘better’”? In fact, a controversy rages on this issue, with arguments made for and against each approach – so it’s worth exploring. One of the major advantages touted for the UML (the standard that governs activity diagrams) is that by providing a single standard across the lifecycle, translation errors are avoided. By this reasoning, it makes sense to use activity diagrams for both business process modeling and for modeling the logic of the software processes that automate them. On the other hand, the BPMN standard is often seen as the more natural candidate for the specific purpose of modeling business processes. In fact, the commonly accepted best practice is for BAs to use BPMN for this purpose (unless there is a compelling reason to use activity diagrams – such as the use of a UML tool across the project) and to use the UML for its other diagrams – primarily class diagrams. Let’s consider the arguments for and against each option to try to ferret out the truth.

Argument #1: Activity diagrams are technical whereas BPMN BPDs are business-y

Because the UML standard came out of the development world, its diagrams are thought to be code-oriented. But this is more an issue of perception than fact. In truth, the UML is a full-spectrum standard that supports both real-world and technical modeling. While it is certainly the case that there are features of activity diagrams that are technically oriented, the fact is that only a small subset of features should be used by the BA when communicating with business stakeholders – and this subset corresponds closely to commonly understood flowcharting symbols. (The same can also be said for BPMN.) I have a strong suspicion that the word ‘Business’ in the BPMN acronym has had as much impact as anything else in this perception of BPMN’s preferred status for business usage. But when you compare the aspects of the two alternatives that are actually used by the BA, feature by feature, there is in fact little difference between the two, as the next argument explains.

Argument #2: As a whole, BPMN diagrams are easier for business stakeholders to understand than activity diagrams

To get past the rhetoric, let’s compare the modeling elements most useful for BA purposes. Figures 2 and 3 show commonly used BPMN symbols along with their activity diagram counterparts. A quick glance indicates that it is hard to tell the two apart. When you look at these elements side by side you really have to wonder what all the fuss is about. There is one situation, in fact, that is expressed in a clearer manner (from a stakeholder’s perspective) in activity diagrams than on a BPMN BPD: parallel activities. Figure 4 compares the BPD and activity diagram symbols used to indicate two activities that may occur in parallel (meaning that they may occur in any order). I think most people would agree that the BPD symbol – a diamond with an enclosed ‘+’ sign, is much more cryptic than the straightforward parallel lines used for this purpose on activity diagrams.

Figure 2 - BPD flow objects (with UML equivalents)

Figure 3 - BPD connecting objects (with UML equivalents)

Figure 4 - BPD parallel fork (with UML equivalents)

Argument #3: BPMN includes special modeling elements that make it more suitable for business purposes than activity diagrams

Here I do believe there is some merit to the argument in favour of BPMN. One situation not well handled by activity diagrams is the Inclusive-OR. This is the logical construct used to model the common expression ‘and/or’ – as in: Do ‘A’ and/or ‘B’ and/or ‘C’ – depending on various conditions. Figure 5 illustrates the approaches used in the two standards. BPMN BPDs are clearly preferable to the mess of symbols required by activity diagrams. Another situation for which BPMN has a dedicated symbol relates to the handling of events. Figure 6 illustrates the difference between the two standards. BPMN relies on the placement of a circular event symbol to communicate to the reader the timing of a response to an event: an event symbol on an activity means that the event interrupts it whereas an event after an activity means that the activity first is completed and then the event is noted and responded to. Activity diagrams have a fairy simple alternative notation for this – but it may not be as readily obvious to the reader what is being conveyed.

Figure 5 - BPD inclusive gateway (with UML equivalent)

Figure 6 - BPD events (with UML equivalent)

Argument #4: BPMN models B2B interactions better than activity diagrams

In the ‘real world’, businesses interact with other businesses in limited ways, whereas organizational units within a single business have more complex interactions. In BPMN, this is modeled using pools and lanes. A business is represented as a pool and an organizational unit within the business is represented as a lane. Interactions between pools are limited to the passing of messages – effectively mirroring the way that businesses pass requests (messages) to each other while being unaware of each other’s internal processes. Figure 7 illustrates this approach. There is no formalism dedicated to this concept in activity diagrams, though the situation is fairly easily modeled by stipulating that businesses communicate by sending and receiving signals. Nevertheless, signals are not widely used for business process modeling and are less likely to be readily understood than pools by business stakeholders.

Figure 7 - BPMN B2B model using pools

Conclusion
For business process modeling, where all the players are within a single business, there is no compelling argument for either standard. While there are some small advantages to each standard, they tend to cancel each other out. (E.g., while BPMN handles the inclusive-or situation better, activity diagrams model parallel activities more clearly.) However, BPMN does have a clearer approach for modeling B2B interactions.

Final words
This discussion has focused entirely on the BA perspective. A separate set of arguments and comparisons could be made with respect to the suitability of the two alternatives for code generation. But that is a topic beyond the scope of this blog.

Howard Podeswa, author of Noble Inc.
For courses designed by the author in Business Process Modeling, click here: http://www.nobleinc.ca/BA005.html

Business Analysis Conference Europe 2010

Adrian M. — Sun, 08 Aug 2010 06:36:00 GMT

The Business Analysis Conference Europe 2010 is building on its highly successful inaugural conference with more workshops and a third track – Business Agility and Business Analysis. It brings together business analysis specialists from across Europe and beyond, providing a platform for promoting the BA profession and opportunities for BAs’ professional development.

The conference runs from 28th to 30th September 2010.

This year we have partnered with the IIBA UK to run an online pre Conference series. Conference speakers will be providing articles to give a real insight into the benefits of attending the Business Analysis Conference in Europe.

One of the keynote speakers, John Seddon, has contributed a piece on the Systems approach to the design and management of service organisations.
The Telegraph described John as a 'reluctant management guru', a description John accepts as his interest is in changing management thinking.

(John Seddon’s key note Conference contribution is described here)

Ellen Gottesdiener and Allan Kelly who are recognized experts on Agile, will share their views on business analysis and Agile from both sides of the pond.

(Ellen Gottesdiener’s Conference contribution is described here)
(Allan Kelly’s Conference contribution is described here)

Joe Da Silva is an experienced business analyst for Skandia who will explore the diverse roles a business analyst can play. (His conference presentation explores his experience in Enterprise Analysis when his organisation recognized the benefits of using internal business analysts instead of expensive, external consultants).

(Joe Da Silva’s Conference contribution is described here)

These are just a few of the articles that are planned and there may be a webinar in the last couple of weeks prior to the conference.

Business analysis is now the central discipline for defining creative and agile options for business change and ensuring that solutions meet business needs. The Business Analysis Conference 2010 will provide an interactive forum where business analysts can learn and debate the essential competencies needed to rise to the challenges faced by their organisations today and in the future.

Read more about the Business Analysis Conference Europe 2010 here.

IMPORTANT DISCOUNTS:
There is a 10% discount available to IIBA members and 15% available to members of the UK Chapter. There is also a discount of up to 25% for group bookings.

Modern Analyst members and Business Analyst Mentor (www.bamentor.com) readers qualify for a 10% discount (Note: this cannot be combined with any other discounts).

When the Client Isn't the Customer

Jarett Hailes — Tue, 03 Aug 2010 00:09:00 GMT

Usually when a Business Analyst is working on a project the client (which I’ll define as the party or stakeholder who receives the benefit of the Analyst’s services) and the customer (the party who is paying for the Analyst to render the services) are one in the same, at least from an overall organizational perspective (i.e. the client and customer belong to the same organization). However, there are times when the client and customer are completely separate entities.

This sort of situation can arise in many environments. For instance, the customer may be an association who wants a new software solution that will be used by its members. Other times an entity may be required by law or regulation to provide certain services to other organizations and a project is struck to create a new solution to address these needs. Regardless of the circumstances, having a separate client from the customer can put the Business Analyst in compromising situations, typically due to divergent needs between the customer and the client.

Typically when a Business Analyst faces a situation where various project stakeholders have differing goals, agendas, capabilities or level of engagement in a project, the project’s structure can usually help resolve differences that can’t be worked out through other means. Within most project structures there will be a project sponsor or steering committee that is responsible for final decisions if consensus cannot be met. However, in a multi-organization project the project’s structure may have little to no representation from the client base. This may not be too surprising, particularly if the project was struck based on primarily internal consultations.

Often the Business Analyst is an advocate for those who will use the end result of the project. To become an advocate one needs to empathize with the client base or else it is difficult to communicate the client’s needs to the other project stakeholders. Once the Business Analyst understands the client’s needs they can often want to see those needs become fulfilled by the project.

However, the customer may not have the desire, resources or mandate to meet these needs. If the customer for whatever reason doesn’t believe that some or all of the client’s requirements need to be met and the project structure does not lend itself to providing the client a voice at the decision table, the Business Analyst may find themselves having a hard time accepting the customer’s position.

When the client and customer are not the same entity the Business Analyst ends up in a type of agency problem; they’ve become an agent for the client whose interests do not align for the principal (the customer). The Business Analyst was tasked with eliciting requirements for the client; if the customer in the end chooses to neglect some of these requirements it can be frustrating or disappointing to see the client’s needs going unmet.

Ultimately the Business Analyst will be faced with a choice to decide how far they will go in representing the client’s needs. Since the customer has the ultimate authority on the project the Business Analyst must determine what level of conflict is healthy to ensure that the client’s needs are being met to the best of the customer’s ability given the overall project environment. Obviously the Business Analyst should work within the bounds of professionalism, but there is a question at what point the Business Analyst should acquiesce to the customer’s expectations.

I don’t believe there is a simple solution or answer to this dilemma, and each Business Analyst will need to decide for themselves where the boundary lies if they encounter this situation. Have you ever been in a situation where your role as a Business Analyst put you in conflict with the project sponsors or Steering Committee? How did you deal with the situation?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

BA ABCs: “A” is for Activity Diagram

Howard Podeswa — Mon, 17 May 2010 04:13:00 GMT

This blog begins a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I’ll be moving through the alphabet, highlighting a BA tool that begins with the letter of the day (not quite Sesame Street, but not PeeWee ‘s Playhouse either). Today’s letter is “A” – for activity diagram.

Example:
The following activity diagram example describes a portion of the workflow for the business process, Review Pursuit – one of the processes within a Customer Relations Management (CRM) system. The two participants in the process are represented by the columns (referred to as swimlanes, or partitions), named “Growth and Markets” and “Pursuit Team.” The example indicates that the process starts when a Pursuit Team reviews an opportunity report. If the review has determined that the opportunity is not worth pursuing, the process ends. Otherwise, Growth and Markets schedules a post-review meeting and discusses required support.
This kind of diagram could have also illustrated which computer systems automated which activities, by depicting the systems as swimlanes - and, in fact, this is precisely what was done in the real case from which this example was derived.

Background on the example:
A number of years ago, I did some consulting for a financial investment firm. The goal of the project was to improve the business process workflow for tracking opportunities and proposals in a Customer Relations Management (CRM) system. The company had been using a number of software products to handle the process – CMS Open for one aspect and PeopleSoft for another. Amongst other things, they were unhappy with the amount of double entry they were doing – entering client information on one system while an initiative was at the proposal stage and doing it again on another system once the proposal was accepted. As a first step, I was asked to develop an As-Is workflow diagram for the current process. Suspecting that one must already exist, I asked to see it but was told that no, there was no diagram. After a while in this business, you develop a sixth sense for detecting when somebody is holding something back so I persisted – and sure enough, the interviewee pulled one out of his desk drawer. I knew it wasn’t perfect (which is why he hadn’t wanted to show it to me) but I was glad to have it – as it was a great aid in facilitating group interview sessions. It’s much easier to look at something and find the errors than to begin from scratch; or another way of putting it: better to have a straw man than no man at all.

The diagram I used showed the steps of the process and indicated who or what system was responsible for each step. This type of diagram is known by many names: Flowchart (which often only shows the sequence of actions but not who does them), Swimlane Workflow Diagram (where the doer of each action is shown) and (if you are using the UML standard) an activity diagram (which may or not show the doer, depending on how it’s drawn).

Context
Activity diagrams are useful in the situation I’ve described – when you need to analyze the workflow of an existing (As-Is) or future (To-Be) business process. In the UML, (using Rational Unified Process [RUP] terminology) are used this way when specifying business use-case realizations (descriptions of the internal workflow used to execute business processes). In this type of situation, they are drawn so that the doer is shown – by indicating a swimlane (or ‘partition’) for each participant.

Another context for using activity diagrams is in describing system use cases. A system use case is a user task – typically a task that a computer user expects to accomplish in a single session on with a software system. The requirements for the interaction between the user and system are usually described in text, but an activity diagram is added if the steps within the text connect to each other in complex ways. (The document that houses all of this is called, in RUP, a ‘use-case specification’.)

Howard Podeswa, author of Noble Inc.

Spring Cleaning Your Personal Backlog

Jarett Hailes — Sun, 18 Apr 2010 04:44:00 GMT

As spring begins to plant its roots in the Northern Hemisphere, many people will begin an annual spring cleaning of their home. All the clutter that has accumulated over the past 3, 6, 9, or even 12 months since the last cleaning is collected, assessed and then dealt with (either by moving stuff to a better location, actually using the thing, or throwing it away/selling it).

Like our homes, most of us have a bunch of ‘to do’s’ that build up over time. Whether you are someone who meticulously manages all the tasks that you must do or you are someone who will try and keep all their ongoing duties solely in your head, chances are that you have a list of things that you have wanted or needed to do but have never quite found the time to get around to. I like to call the list of outstanding tasks that someone has to do (whatever their context; personal or work-related) a personal backlog.

While there’s nothing wrong with not crossing off all your tasks (after all, who really has time to do everything they need or want to?); over time you can develop a level of ‘accountability debt’ to yourself. Most active and high-achieving people strive to get as much done as possible, and when they can’t complete everything that everyone has asked of them they usually take it personally, either at a conscious or unconscious level. This could be manifested as internal guilt, frustration, stress or other negative emotions.

As you feel bad about not being able to accomplish everything you start to make more and more mental reminders of all the things that you haven’t been able to do as if this action itself will help get more tasks completed. This action simply clutters up your brain, which has a finite amount of space for keeping track of things. As your personal backlog list continues to grow, you end up crowding out more pertinent or relevant information from your mind. This can lead to feelings of confusion or lack of focus on the tasks at hand that matter the most.

So, if you’re feeling like you have a million things on your mind, it’s time to perform a little spring cleaning. This activity will involve 4 steps as described below.

Collect

Write down everything you can think of that someone has asked you to do or that you’ve pledged to do. Nothing is too big or too trivial to be included in this list. This should span your work and personal lives; don’t forget about promising to clean Aunt Martha’s eaves troughs (you know she won’t). Include problems that you need to solve (for instance, figuring out how to make your sales estimates more accurate going forward or what to do about your son’s late nights) and that you may need some dedicated thinking time to properly ponder.

This may not be something you can do in one session, but allocate some dedicated distraction-free time to this effort. You will be surprised how many little items come bubbling back to the surface once you get on a roll.

If you already have one or more to do/task lists, this is a great place to start. For this activity you will want to consolidate all of your task lists into one big master list. You may be used to segregating certain aspects of your life and find it effective to manage them that way, but from a spring cleaning perspective you will need to look at everything holistically.

Don’t be surprised (or daunted) if this list grows into hundreds of items; instead take satisfaction that you now have a single point of reference for all your outstanding action items. You no longer need to carry these about in your brain’s short-term memory.

Break Down/Up

You will want to review your list for items that are not immediately actionable (that is, there is something that you would first need to do in order to accomplish the stated item). Those items should be moved to a second reference list and be linked in some way to the one item that is currently actionable on the main list.

This way your to do list becomes a series of ‘next action’ steps, not some nebulous list of end goals that may have dozens of steps that need to be performed in order to be accomplished. Having a list for achievable next steps will add value to this list when you’re looking for what you should do next or at a given moment.

Prioritize

Once you have your master list, it’s time to prioritize. The goal of this prioritization is to have a single ordered list from the highest priority item to the least priority item.

Some of you may want to categorize your items into work and life at this point. I personally find that my life is not so easily segregated (and I would suspect that with modern working practices most people’s are not either), so I would suggest you try and come up with a single prioritized list.

Similarly, you may have a desire to have ‘high/medium/low’ or similar buckets and then just place all your tasks into one of the priorities. While this may be a good starting point so you can manage prioritizing elements further, having buckets of items doesn’t help you actually get any of the tasks done later on. When you’re in working mode, you will want to quickly scan the top of the list and see which of the items are actionable at the moment. Having a list of 10-30 ‘high priority’ items doesn’t help you make a decision at that point, and can lead to feeling overwhelmed and helpless right at a time when you could be easily getting started to work on something.

If you need help getting started, associate due dates to the items that jump out at you off the page as stuff that has to be done by a certain time. This should help you figure out where some of the items fit on the list. Others may not have a set due date but still need to be placed higher up the list.

The end product doesn’t have to be perfectly prioritized; you shouldn’t spend more than a few seconds debating whether one item is above or below another. The goal is to have a general order of importance based on your current life situation that can be easily referred to going forward.

Prune

Once you’ve prioritized your list, start scanning the items from top to bottom. After each item ask yourself “do I really need to get this done?” Once you start running into a steady sequence of ‘no’ answers, start looking for a place to cut off the list and remove all the items below it. Then quickly scan the remainder of the items to see if there’s anything you actually do need to do and bring it back to the pruned list (or perhaps add a couple of items to your pruned list for ‘Sorry I can’t do this messages’).

You need to be honest with yourself and look at your available time, your other commitments and obligations and your personal energy levels and goals to figure out where the line should be drawn. But you do need to draw the line somewhere; I haven’t met anyone who is able to accomplish everything that they put down when they’ve done a brain dump.

Ongoing Maintenance

Once you’ve done this activity, you now have an actionable, up to date and realistic list that you can use going forward to take on your tasks and duties. If you use this opportunity to manage this list on an ongoing basis, you will likely find that your mind will be less cluttered and you will be able to easily find tasks that you can do in any given situation (e.g. those 10 minutes between your meetings) by keeping this list up-to-date and close at hand.

Spring cleaning can feel like a chore, but when you do it on your personal backlog the benefits of a clearer mind and the ability to focus easier without worrying about forgetting to do something can be a major energizer for the months ahead.

BABOK 2.0 Free Download/Access (V2)

Adrian M. — Sat, 17 Apr 2010 04:35:00 GMT

I've seen so many questions being asked by people looking for a free download of the BABOK® 2.0 (Business Analysis Body of Knowledge®).

And the clear answer is yes and no.

Members of the IIBA (International Institute of Business Analysis) can download the BABOK® 2.0 for free from the IIBA's website (login required).

Outside of that, there is no other legal way to download BABOK® Guide.

But do not despair! The IIBA has placed a version of the BABOK® on Google books which, while it cannot be downloaded, it can be accessed via the web and it's free.

Here is the link to BABOK® Guide you can access for free:

Business Analysis Body of Knowledge® (BABOK®) on Google Books

While not a free download, there are also other ways to get information about the BABOK®:

Article: An Introduction to the Business Analysis Body of Knowledge (BABOK 2.0)

Buy a hard copy of the Guide to the Business Analysis Body of Knowledge (BABOK®)

The Lost Stakeholder Analysis Dimension: Engagement

Jarett Hailes — Fri, 19 Feb 2010 03:13:00 GMT

Stakeholder Analysis is an important and often ongoing activity that Business Analysts perform as part of their duties. Solution delivery team members need to understand who else is involved or impacted by their work effort, how they can interact with these people or groups, and what sort of tradeoffs exist in pleasing one group over another.

The BABOK highlights several important dimensions that can be collected on each stakeholder, namely:

The stakeholder’s attitude towards the project or solution team

The stakeholder’s influence on the project or solution team’s success

The type of stakeholder (internal/external, direct/indirect, etc.)

The body of knowledge also describes artifacts such as a RACI chart and stakeholder map to help manage the information you collect on stakeholders.

In addition to these dimensions, I believe that there is another consideration that needs to be included in stakeholder analysis: the stakeholder’s engagement level with the project or solution team.

A stakeholder’s engagement level describes the expected or actual amount of involvement a stakeholder has with the project. Since the required level of engagement with certain stakeholders may differ over the course of a project, this level should represent the level of engagement relating to activities that could or should involve the given stakeholder. In some cases, you may wish to separately track the expected/needed versus actual amount of engagement.

This is an important dimension to consider for several reasons:

The level of engagement that a stakeholder provides can greatly impact the amount of effort required to perform other Business Analysis activities, including requirements gathering/validation, solution assessment, enterprise analysis, etc.

If you expect to see high levels of active engagement from certain stakeholders who may not be considered high priority in the overall context of the project, you may find that the team will spend a disproportionate amount of time dealing with these stakeholders. By identifying such potential issues up front mitigation strategies can be developed to ensure that efforts are focused on where the highest needs are.

Conversely, if you identify high priority stakeholders with likely or actual low levels of engagement the team can identify potential solutions to address the causes of such disengagement, escalate this issue with the sponsor as needed, or allocate sufficient time to ensure that these stakeholders’ needs are still adequately met.

The Engagement Gradient

Every stakeholder’s level of engagement can vary. I use 4 markers as generic signposts to describe the general level of engagement each stakeholder has.

Proactive: these stakeholders are heavily involved in project activity. They are not only willing and able to answer questions, but they’ll ask you questions you haven’t thought about yet. They want to trial out potential solutions, volunteer for committees and the like. Generally they behave as an active team member rather than a stakeholder.

Responsive: these stakeholders get involved in the process, but only when prompted. They will respond to surveys, join in interviews or workshops, and provide suggestions to outstanding items but they won’t go out of their way to let you know something or volunteer to actively work on issues.

Marginal: these stakeholders will participate on occasion, but not all the time. They will provide limited feedback, give short responses, not really contribute meaningfully to discussions or suggest solutions to problems. Such stakeholders can quite often feel obligated to be involved (although if this is the case it should be documented separately in the attitude section).

Disengaged: these stakeholders you rarely or never hear from. They will not respond to meeting requests, surveys, etc. When they are present it’s virtually impossible to get them off their Blackberries or do anything beyond nod their head (either in agreement or disagreement).

You may find that some stakeholders exhibit various markers depending on the subject or issue at hand within a project. If appropriate you may have a matrix of engagement levels for your stakeholders with the stakeholders and the various aspects of your project representing the axes.

Leveraging Engagement in Stakeholder Analysis and Other Activities

By bringing in the engagement level dimension into your stakeholder analysis, you can now optimize your other Business Analysis activities much more efficiently. Taking this information into consideration in conjunction with the stakeholder’s attitude and influence towards the project can help identify potential risks to the success of the project, find potential bottlenecks in upcoming project activities and look for ways to improve stakeholder communications.

For example, let’s say that you have a stakeholder with a great attitude, is proactively engaged but of low influence to the project? Such a stakeholder could have the potential to take up a lot of the project’s time. Perhaps you can look to leverage their enthusiasm for the project by having them spread the word of the project, get other higher priority stakeholders on board, etc.

When a stakeholder is disengaged there could be several causes. If the stakeholder could pose a major influence on the project I try and determine whether the main reason is lack of time or lack of interest. If it’s the former then we can work on finding ways to involve them in more asynchronous activities or to get them involved at a higher level, if appropriate. If it’s the latter then I know the project may have a potential problem – perhaps the apparent value of the project is not there, or more work needs to be done to ensure this stakeholder sees the value and thus will contribute more to the project.

Looking at the overall engagement of all stakeholders can also give you an idea as to how well your engagement activities are being received. If it looks like most of your stakeholders are not very engaged with the project you may wish to review your communications plan as well as your other stakeholder activities and ask if you have had sufficient input in order to proceed.

It is important for a Business Analyst to acquire and deliver the right information from the right people and organizations within the course of their duties. Stakeholder analysis activities can help a BA navigate the sometimes challenging waters of ensuring that everyone has their voice heard and are sufficiently involved to ensure the project or solution is a success. Understanding the anticipated/desired and actual levels of engagement with stakeholders can help ensure that project goals are met.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Why I Don't Use BPMN

Jarett Hailes — Wed, 10 Feb 2010 01:59:00 GMT

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification. I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise. I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations. Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN. One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.”

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.”

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions. The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before. BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines. If there is interaction across the pools then a message flow is used. Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff. With BPMN this is not always readily obvious since all pools continue along their own process flows. I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl. Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily). While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one. To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved.

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes. The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.” BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model.

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready. BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses. Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible. In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use. While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill. When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart. This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components. I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact. Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth. I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process. In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Root Cause Analysis: Using the Five Whys

Jarett Hailes — Tue, 26 Jan 2010 00:55:00 GMT

Business Analysts are often thrown into projects to help gather requirements around a known, defined problem. Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking. I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues. For example:

· This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance

· This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them

· This process is obsolete and overlaps with three of our other processes

While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue. If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution.

A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’. When an issue is presented you ask the question ‘why did that issue occur?’ Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.

Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems. Recently I came across a similar example with a client (certain details have been changed).

Issue: Employees did not receive their pay stubs on pay day.

· Why? Because the printing system failed the day before pay day.

· Why? Because the system could not recover from a hardware fault.

· Why? Because the system uses outdated hardware that has no automatic redundant backup.

· Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.

· Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Some people may have been tempted to stop after the third or fourth question. We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure. Or we could have determined that the system needs to be replaced and develop a business case to do so. But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.

It may still be a good idea to address the symptoms found during this activity. In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility. The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.

The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Mitigating the Risk of Story Point Drift

Jarett Hailes — Mon, 18 Jan 2010 01:38:00 GMT

In many Agile projects requirements are not typically written in the form of a formal requirements document. Instead, a collection of concise but effective means of describing what must be built called user stories are often used. User stories describe the behaviour, performance, or interface of a system from a customer’s perspective. A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artifacts, they are also essential to estimate the scope/size of the project and to track the progress of the team. When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject).

Agile teams will often use a unit-free type of measure called story points. The advantage of using story points is that their inherent value is relative. Instead of trying to come up with absolute values typically related to time (for instance, how many days will it take to complete feature X), story points are only concerned about the relative effort or complexity of a story compared to the other stories that have been or need to be completed. When the total number of story points for the project is combined with a team’s velocity (the number of story points completed per iteration period) project stakeholders are able to get an increasingly accurate picture of the size of the project and the time it will take to complete given the current team.

Initially when the team forms they will estimate story points for some number of baseline stories. For instance, the team may have the following 3 stories as their baseline:

As a user I want to browse the book collection by subject: 8 points

As a user I want to be able to save my payment information: 2 points

As a user I want to be able to recommend my favorite books to people: 5 points

From this baseline other user stories are estimated in terms of their perceived relative amount of effort to accomplish. For larger projects, most user stories are estimated as epics, larger user stories that will be broken down later on in order to actually tackle development.

Over time, new user stories will be added to the product backlog, others removed and some will be altered to reflect changing requirements. All the stories that are added or changed to the backlog will require story point estimation.

One of the potential risks that exists when using story points is what I call ‘story point drift’. Story point drift is when user stories that had a given story point value at the beginning of the project require substantially more or less effort than stories with the same story point value later on in the project for the given amount of effort required to complete a story.

For instance, let’s say I have the following user stories estimated later in the project:

As a user I want to be able to have my bank account linked to my login and set up a monthly withdrawal plan: 8 points

As a user I want to have a theme editor that can customize the look and feel of my online affiliate store: 5 points

While the above user stories may accurately represent their relative size compared to each other, in comparison to the stories that were estimated at the onset of the project it appears as though the latter group’s story points under-represent their complexity and level of effort required. I would suspect that the amount of work to enable automatic bank transactions is substantially larger than the amount of effort required to build a browse by subject feature.

I find the risk of story point drift increases on larger or longer-term Agile projects. Story point drift can occur for several reasons:

The team’s collective memory is short term: when a team begins estimating new stories, they typically draw upon their experiences from recently completed stories. If some of those stories were misclassified (either required materially more or less relative effort than was represented in the story point estimate), then the team can end up believing that these recent stories are the new norm for the value of the story points and use these as references going forward, which skew the story point values from the original baseline references.

The team’s complement has changed: it is not uncommon for project teams to change over time. I’ve noticed that even as teams get larger or smaller that a team’s velocity can appear to remain constant. When investigating this, I’ve found that it’s often because the team begins to estimate stories with fewer points, since they now feel that the story is ‘easier’ since there are more people to work on the project. As a result stories that might have been considered 8 points previously are now being estimated as 5 points. As a result, despite the fact that the team is likely getting more done given their drift in estimates the team’s velocity appears unchanged.

Baselines are not referred to: Agile projects usually thrive by the minimization of overhead that does not lead to customer value and by adapting to non-ideal situations. For example, Agile teams rarely wait for everyone to show up for a meeting – the meeting is time-boxed and starts and ends on time regardless of who is missing. However, at times Agile teams may forget to bring physical objects like their reference stories to meetings. Sometimes teams will try and get through the meeting based on recollection rather than actual reference. Without the actual reference stories and point values in hand, the resulting estimates can be somewhat skewed.

When I’ve seen story point drift it has occurred in small increments over time – you don’t realize that there’s been a dramatic deviation in the estimates until sometimes months later. Story point drift can cause issues with resource planning and progress and time to completion estimation. Here are a couple of strategies I’ve used to help mitigate story point drift:

Bring mixture of original and recent stories as the baseline for new estimation: it never hurts to hold up your original estimates when doing relative comparisons. Having some recent examples are also helpful, in particular since your initial estimates were likely only for a few potential story point values. Having 1 or 2 stories for each possible story point value can also be helpful when discussing what level of estimate to assign to a new story, or when individuals are deadlocked in a session of planning poker.

Know when certain stories should be re-estimated after implementation: once in awhile you will encounter a story that was a lot more (or less) effort than you initially thought. If the level of effort was sufficiently different from another story that was given the same amount of points, you may want to re-estimate the story so that it does not affect your team’s perception of the value of a certain number of story points. I typically would only re-estimate a story once a project has been going for several Sprints – early on you may discover that many of your stories take less or more effort than you thought and you’ll be tempted to resize those stories. However, as long as the stories are taking about the same amount of relative effort, then there’s no need to re-estimate. So if you thought your 3 point stories would take a day to complete but they’re taking the better part of a week, check to see how your 5 and 8 point stories are taking. If those are also taking a fair bit longer than anticipated, then don’t re-estimate.

Spend a little time every few Sprints and analyze relative stories: the ScrumMaster or Project Manager can review some of the completed stories over time to look for possible story point drift. If some drift is detected, bring it up with the team and see what they think. If the team agrees, then re-estimate the stories that appear to be out of what in terms of relative effort.

User stories and story points can be a very good way to manage the requirements and estimation for a project. Keeping an eye on story point drift will ensure that the team has a good handle on the project’s rate of progress and estimated time to completion. With diligence this method of project estimation can be a very accurate and effective tool for Agile teams.

-------

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Agile Development: What we can learn from property developers – or what they’ve learned from us

Howard Podeswa — Sun, 13 Dec 2009 05:01:00 GMT

Readers of this blog (both of you; I know you’re out there!) may have gathered by now that I’m a big fan of mixing it up: art/science/business/philosophy/politics/psychology and anything else that can be thrown into the pot. I believe that the more you let your worlds bleed into each other, the more opportunity there is to benefit from the cross-pollination of ideas.

I had a vivid example of this recently. I was having dinner with a friend of mine – who also happens to be a gifted architect and designer. We were talking about a project he is working on where he is responsible for handling design aspects of a large commercial property development. One of the things that struck him as particularly challenging on this project was the fact that the buildings were literally going up as the design was being worked on. This meant that many different activities were going on at the same time. Instead of going through a single pass of upfront design followed by construction, they were developing this project in a set of short cycles; each time through they pinned down the requirements for an aspect or area of the complex, did just enough design to get it built and then constructed it on the ground.

Sound familiar? What he was describing was iterative-incremental development – an approach to managing software projects that is the basis of agile approaches, IBM’s RUP (Rational Unified Process) and Microsoft’s MSF.

It’s interesting to note that the classic (i.e. older) approach to managing software projects was based on the how the construction industry managed its projects at that time: a single cycle of requirements analysis, design, testing and construction, known in the IT world as the ‘waterfall’ approach. That got me wondering whether the influence is now flowing on the opposite direction. Are managers of construction projects now learning a trick or two from their counterparts in the IT world?

These are not rhetorical questions. I’m expecting an answer – or at least looking forward to your comments, and maybe even instigating a little cross-breeding for those of you who have friends in the design or construction industry. To wit: Does anybody out there know when iterative development began to take off in the construction industry? For those of you with friends in the design, construction, or property development sectors: Do you know of any examples of iterative construction projects and, if so, what are the challenges and lessons learned?

By the way, I asked these questions of my friend, the architect, in order to see if there were any ‘lessons learned’ that could be applied to the IT world. He told me that the biggest challenge for the design shop, was to avoid making a decision they would later come to regret. This was a real risk, because they were designing while some of the requirements were still unknown. It’s a challenge BAs on iterative projects should all be able to appreciate. Asked how they were mitigating this risk, he summarized their approach as follows:

Don’t commit to something today that you can put off till tomorrow. In other words, if you can delay a decision without delaying the project, put the decision off. But if you have to make a decision, then …

Choose the option that least constrains the future. That way you minimize the impact of making a wrong decision.

Here’s an example of how the second principle works in his industry: The designers were required to put in a staircase before they even knew how the rooms on that floor were going to be used and what their individual sizes and layout would need to be. So the designers chose a staircase position that left them with the most flexibility for laying out the rooms later. In this case it meant rejecting a central staircase, because it would rule out options for room layouts more than a staircase off to one side.

You can see how these lessons can be immediately applied to IT projects. As to which sector originated the idea of iterative development, one thing is certain: Wherever the iterative idea started, everyone who is doing it – regardless of the sector they’re in – has a lot to learn from each other. Let’s get the conversation started.

Howard Podeswa, author of UML for the IT Business Analyst

Eliciting Business Rules with an Eye for Data Requirements

Adrian M. — Fri, 27 Nov 2009 06:31:00 GMT

“Business Rules and Data Requirements: Pulling in Tandem for Success” was the title of another session I attended at the WCBA conference. Mary Gorman, Senior Associate with EBG Consulting, focused on business rules and their relationship to data in the context of requirements elicitation.

Copyright Notice: Major portions of this blog post are from materials © EBG Consulting, Inc., 2009 Used with permission on ModernAnalyst.com

Before even diving into the mean of the presentation, Mary stressed the importance of realizing that no one requirements view or model is enough, by itself, do understand the requirements of a given system.

She covered again the four key requirements viewpoints:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules – the intersection of Behavior, Structure, and Dynamics

All these four views are very important and rely on each other to provide a holistic perspective of the requirements.

They key takeaways, for me, from the sessions were:

Process/behavior requirements cannot stand by themselves but instead they trace to data and business rules (just process sis like sitting on a one legged stool)
There is great risk when performing single-dimension requirements elicitation focusing on only one of the requirement viewpoints: business rules alone, business data alone, business process alone, etc.

That’s why you don’t see too many dedicated “Business Rule Analysts” or “Business Process Analyst”. The analyst must be a generalist or, as Scott Ambler likes to say a “specializing generalist” emphasizing that while you might want to specialize and be proficient in one or two disciplines (like business rules analysis, process analysis, etc.) you must also have a good understanding of all the other business analysis dimensions. Focusing on one area alone is like trying to sit on a one legged stool… you’ll be on the floor before you know it.

Identify Business Rules

When eliciting requirements, it is great if you are able to identify business rules as soon as you hear them even they might not be labeled as such by your stakeholders. To accomplish this, Mary suggests that the analysts watch for certain key words which serve as business rule giveaways.

Here are some of the business rules clues:

classify,
determine,
compare,
assess,
evaluate,
must,
defined as,
must not,
calculated as,
must only,
If … then …
etc.

Business Rule Classification

Term Rule: a business rules which defines a term of the business…. In every business domain it is critical to document all the rules defining the vocabulary to be used on the project.

Example 1: A Customer is defined as an individual or organization who purchased a product in our store.

Example 2: A Gift Card is defined as a product sold by our store that in turn can be used as a payment for other purchases.

As you can probably guess, your project glossary is a set of term business rules.

By the way, for more details on business rules in the context of requirements elicitation process check out the The Software Requirements Memory Jogger.

Fact Rule: Is a business rule which is part of the “fact model” (think logical data model) which outlines our understanding of truth related to previously identified terms.

Article 3.2 of the Business Rules Manifesto states: “Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.”

Example 1: A Purchase is paid for by Gift Card, a Gift Card pays for a Purchase (shows the relationship between Purchase and Gift Card).

Example 2: A purchase may be paid by one or more Gift Cards, A Gift Card may pay for one or more Purchase (shows the cardinality between Purchase and Gift Card).

As you can see from the above two examples, fact rules are really facts which are generally documented and captured by logical data models of your system.

This example also reinforces the concept that while doing analysis of the business rules you will discover data requirements (business entities and their attributes) such as: customer, customer e-mail address, gift card, gift card balance (entity vs. attribute).

It is not possible to analyze business rules and not consider data requirements:

Fact Rule: a customer has a name and address
Data Attribute: customer first name, customer last name, customer semail address (attributes are atomic – cannot be broken down any further)

Constraint Rule: is a business rule which places a constraint on data entities or data attributes.

Example: A Gift Card’s expiration date must be equal or greater than the Purchase’s purchase date.

Again, from the rule above you’ll see that we just discovered a data requirement to track and store yet another piece of data => Gift Card Attribute: expiration date (we need to remember the date in order to be able to enforce the constraint rule).

Derivation Rule: Is a business rule which explains how new data may be derived from other data. Think of these as calculations.

Example: Gift card expiration date is calculated as Gift Card activated date plus 365 days.

And, of course, here is another new data requirement -we need to store yet another Gift Card Attribute: activation date.

Did you see how rules drive data – you discover data as you discover and document the rules.

Data Attribute Rule: Is a business rule which provides constraints on data attributes.

Example 1: Customer’s middle initial is an optional attribute when of purchasing a Gift Card.

Example 2: Gift Card Status has four allowable options: Purchased, Activated, Expired, and Depleted.

Mary suggested using a table as one option for capturing and documenting data attribute rules, such as:

Attribute Name	Definition	Required	Allowed Values	Data Type	Maximum Value	…
Customer first name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer last name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer middle initial	…	No	n/a	Alpha	n/a	…
Gift card purchase amount	…	No	n/a	Currency	n/a	…
Gift card status	…	Yes	Purchased, Activated, Expired, Depleted	n/a	n/a	…
Gift card original balance	…	Yes	n/a	Currency	$1,000.00	…

Of course, you can add additional columns to capture more detailed requirements about your data attributes such as: format/mask, minimum value, range of values, etc.

Separation of Concerns

Do your data definitions belong in your use case (or other behavioral artifact)?

Do your business rules belong in your use case (or other behavioral artifact)?

NO! They need to be in a separate/shared repository so that they can be reused.

One of the key concepts which were stressed in this session was the separation of concerns. While you may be doing it all during the requirements process: rules, data, process/behavior you also need to ensure that you have a way to manage the project’s processes, data, business rules, etc. as separate (yet interconnected) models rather than dumping your requirements into one catch-all document or format.

In her session, Mary Gorman covered many other topics related to business rules but this post would have been even longer. Sorry - but I guess you'll have to hear her in person.

If you’re interested in my notes from Mary’s other WCBA session, visit: Jogging through the IIBA® BABOK® with the Requirements Roadmap

Useful Business Rules References

Book: Business Rules Concepts by Ronald Ross

Article: Business Rules and Data Requirements by Mary Gorman

Article: Turning Rules into Requirements by Ellen Gottesdiener

Interview: What Analysts Need to Know about Decisioning and Business Rules - Interview with Ronald G. Ross

Business Rules Manifesto: The Principles of Rule Independence from the Business Rules Group

The Business Rules Manifesto*

Article 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a rule’s truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. ‘More rules’ is not better. Usually fewer ‘good rules’ is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Copyright, 2006–2009. Business Rules Group.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.

Dispatches from the WCBA Conference: Retrospectives

Adrian M. — Wed, 18 Nov 2009 18:51:00 GMT

Dispatches from the WCBA Conference: Retrospectives

“Slow Down to Speed Up: Retrospectives for Improving Product and Process” was the title of one of the workshops I attended during day two of the WCBA conference.

Ellen Gottesdiener, Founder and Principal Consultant, of EBG Consulting tackled the subject of “Retrospectives”.

It was a great presentation and included a number of topics including:

What are Retrospectives?

“Retrospective – a ritual in which the entire project community comes together: reviews the iteration/release/project story (something which just finished), harvests the collective wisdom of the teams, tells the truth without blame or judgment, identifies what to appreciate and improve, understands and forgives its failings, and relishes in its successes.”

In a nutshell, it’s our chance to look back in the rear view mirror and learn from what just took place. The insights gained from retrospectives become the basis for improvement, both immediate and longer term.

Careful using terms such as postmortem (are you assuming you project is dead?)…

In order for a retrospective session to provide value, it must address 5 key questions:

· What did we do well that we might forget if we don’t discuss it soon?

· What did we learn?

· What should we do different next time?

· What still puzzles and intrigues us?

· What needs more in depth discussion and analysis?

When should Retrospectives take place?

The traditional practice for doing retrospectives or postmortems (if your project is dead projects) is at the end of the project. The problem with this approach is that on projects with longer duration the value and benefit of the retrospective diminishes as it is far removed from when most of the project activities took place.

Alternately, retrospectives can be done sooner than the end. For projects which have a set rhythm (regular iterations, regular releases, etc.) a retrospective session can be done at after of each of the repeating phases.

Lastly, you should also consider an ad-hoc retrospective as a valuable tool when you get caught by surprise by a project challenge or other significant unplanned event in the life of the project.

Why Retrospectives?

As with everything else that we do, retrospective must provide value in order to be worth the time and energy. Ellen explored the value proposition of this tool.

In a nutshell, retrospectives are a great way to harvest the collective wisdom of the entire project team by giving everybody a chance to tell the story from their perspective and to discover things that happened on the project that you did not know about.

Retrospective is a great method of free adaptive learning:

· Immediacy – doing the retrospective as soon as possible ensures the recent experiences are sharp in the team’s memory,

· Relevance – the learning is relevant because the team has a common vested interest in the project/milestone/iteration/release what just completed,

· Self-Direction – most of us we don’t like to be told what to do ->retrospectives allows the individual contributors to identify and choose what they want to adapt and change going forward.

Retrospectives that Work

A retrospective is a great community participation-based tool which works because needed change is identified, proposed, and implemented by the project team and not simply shoved down their throats by some executive who is disconnected from the day to day realities of the project.

Successful retrospectives:

· Use data -> how many stories we implemented as opposed to the last iteration, how many test cases per story, how many defects per function point, etc.

· Acknowledge individual feelings -> Remember that feelings do count!

· Have a pre-defined structure –since everybody knows that it will take place, it provides the freedom to participants to identify and implement change without fear or guilt.

A good structure for your retrospective session looks like this:

1. Readying – set the stage

2. Past – gather data

3. Present – generate insights

4. Future – decide what to do

5. Retrospect – close the retrospective (retrospect the retrospective)

Retrospective = basis for change – it’s really a very cheap, yet effective, change management strategy

Dispatches from the WCBA Conference: Jogging through the IIBA® BABOK®

Adrian M. — Tue, 17 Nov 2009 08:55:00 GMT

Here’s a dispatch from the first day at the World Congress for Business Analysts (WCBA).

I attended an all-day workshop titled “Get the Right Stuff, Fast: Jogging through the IIBA® BABOK® with the Requirements Roadmap” lead by Mary Gorman of EBG Consulting.

Mary is a Certified Business Analysis Professional™ (CBAP®) and works as Senior Associated for EBG Consulting, assisting teams to build the right products through exploring and confirming their requirements.

If Mary’s sessions was a jog, then this blog post will be a sprint – a very fast one, I might add!

The focus of the workshop was to:

Leverage the Requirements Roadmap to articulate requirements
Align requirements models to knowledge areas in the BABOK®
Create a set of interconnected requirements models to speed up the requirements development and successfully engage business users and customers.

During the session, Mary provided great insights on the business of “business analysis” specifically focusing on defining the scope of and modeling user requirements using the requirements roadmap:

You can get the PDF version of the requirements roadmap from EBG’s website.

During the session we raced (ok, just jogged) through the roadmap with pointers to sections in the various BABOK® knowledge areas:

Business Analysis Planning and Monitoring
Enterprise Analysis
Elicitation
Solution Assessment and Validation
Requirements Analysis
Requirements Management and Communication

Regardless of what methodology or techniques you use, Mary pointed out that it is important understand that we need to have a balanced perspective of the requirements through the lens of four fundamental model views:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules

The session slide included a nice Vann diagram of the four models with the control model being at the intersection of the behavior, structure, and dynamics models.

Jogging along… the session covered a number of techniques, including:

Stakeholder & Actors: Customer vs. User vs. Others => Ask: “Who?”

Glossary & Data Model: The building blocks for later constructs such as business rules => Ask: “What?”

Event-Response Tables: An effective tool to elicit user requirements => Ask: ”When?”

Use Case & Scenarios: Describe the flow of the actor-system interactions => Ask: “How?”

Business Policies & Business Rules: Statements that constrain some aspect of the business => Ask: “Why?”

The practical side of the workshop was the case study which forced everyone to roll-out their sleeves and put in practice the techniques discussed.

It was a cozy sessions with many chances for everybody to participate. Most of the session attendees got a free copy of the Software Requirements Memory Jogger.

- Adrian

Adrian Marchis
Publisher, ModernAnalyst.com

Art and IT: Two Solitudes?

Howard Podeswa — Fri, 10 Jul 2009 04:01:00 GMT

In these ‘tough economic times’ everything seems to be measured in dollar value and if that kind of value isn’t readily discernable, we often assume there is no other value either – or none that matters. It’s behind personal financial expert Suze Orman’s diatribe against teachers (who, according to Suze, can’t possibly have any self-respect if they’re willing to work for so little money), and behind a general devaluation of arts and culture - other than those aspects that have a proven monetary value. I think we’re missing something that the artists and scientists of the Renaissance period understood well, when an artist, poet, architect and scientist were not necessarily different individuals.

These thoughts came to mind as I was showing a copy of the new edition of my book, UML for the IT Business Analyst to a friend who is an artist. I pointed out the new painting on the cover, and he recognized it right away from a previous exhibition. But there the interest ended. Unsurprisingly, he had no idea what the diagrams inside meant - but he could not even entertain the idea that he might be able to understand them. It got me wondering why it so unusual for somebody who works in the arts today to have an aptitude or interest in ‘computers’ (by which I really mean software design and analysis, as opposed to, say, being able to use applications like Photoshop, which almost every visual artist knows how to use).

As in the arts – so in business: eyes roll when the subject turns to IT (Information Technology). Some people are just not that into it; but sometimes it’s just that they are intimidated by it - convinced from the outset that they’ll never get it. It’s a protection mechanism. (Either way, it’s something BAs need to be aware of. One practical implication, for example, is that the documentation that is presented to non-technical audiences should not lean too heavily on analysis diagrams: their association with IT is enough to damn them for many readers.)

In any case, I don’t mean to rag on my artist friends. The ‘2 solitudes’ argument cuts both ways. Few of my friends in the IT world are interested in art either: they don’t go to art shows, don’t buy art (posters don’t count); don’t look at paintings or ‘art’ photographs. The reasons, I think, are pretty much the same as for the artists who don’t do IT: not interested, or convinced they’d never get it. For the second group - those who are simply intimidated by art but want to know more, it helps to have a guide.

At the moment (and for the next week), I have a show of paintings up in a gallery. I’ve been taking people on ‘guided tours’ of the show – each time focusing on a different piece.

This blog is a virtual version of that – focusing on one of the paintings in the current show, ‘Colossus’.

The title refers to another painting by the same – ‘The Colossus”, attributed to Francesco Goya, a Spanish painter who painted it in the early 1800’s. Goya lived in a time of great upheaval and war – and this is reflected in his work. In the original painting, the Colossus is a giant man who towers in the sky above the human turbulence below.

My painting is not an attempt to redo the Goya; it’s more of a riff on it. In my version, the Colossus of the Goya has been replaced by … well, me. But I’m standing on solid ground, not striding across the sky. And I’m wearing Sorel winter boots. (Because this is Canada.) This is one of the first paintings I started while working on the show, but I finished it last. It’s a summing up of all that I’d done in series. Its subject is war and people on the move, the migrations we hear about every day in the news and the endless migrations that have preceded them. The people in the painting come from: a photograph, a painting of a village by the French artist, Eugene Boudin, and one or two Black paintings by Goya – a mixing of pasts and the present and timeless wanderings.

This remixing of disparate sources is something that art - the process of making it and looking at it - excels at: the ability to see, as in this case, that there is a way to make a connection between a contemporary photograph, an early French Impressionist painting and some very sombre Spanish depictions of the human condition in times of war.

Whereas science and technology are largely about following disciplined, repeatable processes to arrive at a result, art encourages the mind to wander between ideas and see unexpected relationships. It's a skill the Business Analyst needs to develop when looking, for example, for a common thread behind a slew of customer complaints or when coming up with a novel approach to solve a problem.

There's a bleed, in other words, between the ways of thinking promoted by art and those promoted by science. Which is why I think it's a good idea to explore both, as opposed to staying within one silo ... not that there's anything wrong with that.

And a couple more art links:

Howard Podeswa

P.S. After much work, the new edition of UML for the IT BA is now being printed. Many thanks to all those in the ModernAnalyst community who contributed their thoughts via this blog. While I wasn’t able to thank you all individually in the book, there is a big shout-out to the group in the book’s acknowledgements and, in particular, to Adrian Marchis, for establishing and supporting this vibrant community.

The 8 key responsibilities for Business Analysts on software projects

Adrian M. — Sat, 04 Jul 2009 04:24:00 GMT

I stumbled upon a great blog post by Jerry Nixon, Principal Architect for NixonCorp, which covers from a developer's perspective eight reasons why Business Analysts bring value to a project through what they do:

Extract
Anticipate
Constrain
Organize
Translate
Safeguard
Simplify
Verify

Read Jerry's post for the details.

- Adrian
Adrian Marchis
Publishing Editor, ModernAnalyst.com

I want to be a Business Analyst… Raise me, mentor me, and set me free!

Adrian M. — Sun, 07 Jun 2009 22:05:00 GMT

“Once upon a time, young people learned a trade through years of apprenticeship.”

Have you noticed an interesting dilemma faced by those wanting to enter the business analysis profession?

There don’t seem to be any “Junior Business Analyst” jobs. Most hiring organizations are looking for practitioners with prior business analysis experience.

Imagine wanting to begin a career as a driver and being told “You can’t drive the car until you know how to drive a car.”

And when you ask for advice on how to learn to drive a car you get answers such as:

“Here’s a list of good books about driving cars.”
“Talk to other drivers about their experience and how they got started.”
“Try first a related career such as car washing, car repair, etc.”
“Subscriber to Car and Driver magazine.”
Etc.

Sounds silly?

Well –that seems to be how we treat newcomers to our profession:

Managers want to hire the experienced Business Analysts for their projects but they don’t seem to want to grow BAs, and
Experienced practitioners want to work with and learn from other experienced BAs but they don’t want mentor junior ones.

Is business analysis a really a profession? Are we there yet?

I’m not so sure!

In most mature professions you will find that, in addition to the educational requirements which may exist, there is always a “practical” component to the path to getting started as a newbie:

Carpenters, auto mechanics, and plumbers have apprentices who are taught the trade.

Medical school graduates go through lengthy residency and fellowship programs where they gain real experience.

Law enforcement academy graduates are generally assigned to a training officer with whom they will spend months, if not years, on the street learning the realities of the profession.

If you want to learn to drive a car you are allowed to get behind the wheel and learn to drive even before you master the skill enough to pass the driver’s test.

That’s what we need in our profession!

We need managers, practitioners, visionaries, and leaders who are willing to hire newbies and help them start their careers as business analysts.

If you’re a newbie I bet you would love to find an organization who is willing to hire you right out of school/training, get you started as a business analyst, mentor you, and the launch you into a successful business analysis career! Wouldn’t you?

Helpful resources:
In this month’s issue of the Modern Analyst eJournal, you’ll find some great thought leadership on the value of and establishing Business Analysis Communities of Practice (BA COP) or Business Analysis Centers of Excellence (BA COE) which can act as the starting point of BA apprenticeship and mentoring programs.

Also in this issue you’ll find insightful articles on the Business Analyst Career Progression and the Potholes of Office Politics that new BAs may be faced with.

And in the spirit of providing you with a solid technical background, we continue our SOA series with an introduction of More Confusing SOA Terms.

- Adrian

Adrian Marchis
Editor, ModernAnalyst.com